The reason for this difficulty is that existing smart phones or other devices will display unintelligible or junk characters in place of the intended Chinese characters indicating SSID information in that language. To make matters worse, even if the user guesses and selects one of the access points to connect to, the smart phone is typically not able to establish a connection with the selected router or hot spot. Some smart phones are not even capable or recognizing or scanning an access point when the SSID is configured in Chinese, Indian, Spanish, etc. This is a significant limitation of smart phones from the perspective of many users, because a smart phone which is expected to connect with any WiFi™ hot spot in the world can actually paralyze the complete WLAN feature of the smart phone when the phone's user tries to connect to those hot spots which are configured with non-English SSID's, as mentioned above.
In terms of smart phones based on the Android™ operating system, the reason that Android™ phones display “junk” characters for Chinese or other languages is not because the Android™ graphical user interface (GUI), which is powered or supported by the Java™ framework, does not support Chinese characters. Instead, a significant part of the difficulty lies in the way processing of SSID information is handled in the existing Android™ operating system and related logic. More particularly, the Android™ framework, including the supplicant module used to establish connections to hotspots, is completely unaware of the encoding format in which the SSID name is encoded in beacon frames broadcast by the access point. Instead, smart phones based on the existing Android™ operating system merely and always assume that SSID information passed to them is in Unicode (UTF-8 code) format. This default processing of character sets results in anomalous behavior if the SSID is encoded in a coding format other than Unicode. As noted, wireless routers or other access point devices may be encoded in non-Unicode formats in many regions of the world, including as noted China, as well as other locations.
To consider the existing SSID format used by smart phones connecting to WiFi™ access points, the SSID information is presented in an SSID Information Element identified by Element Id: 0, in a structure which is illustrated in FIG. 1. The SSID IE shown is mandated by industry standards published by the Institute of Electrical and Electronics Engineers, or “IEEE.”. As per this SSID IE which is defined by the IEEE standards, the only significant information conveyed is the SSID name and the length of the SSID. There is no additional information that is available to assist in identifying the character set, associated language, or other extended characteristics of a WiFi™ access point.
A scenario can likewise be considered in which there are two access points transmitting and announcing their SSID's, which might be in English and Chinese, respectively, within a local broadcast range. As expected the SSID IE's broadcast the SSID's, but the English SSID is encoded according to ASCII code set, whereas the Chinese SSID might be encoded according to the official Guo Biou (GB) code set promulgated for Chinese character processing.
The smart phone supplicant module, which interfaces between the Java™ framework and the underlying WLAN driver and other transceiver logic, receives these two SSID IE's from the WLAN interface. The supplicant module passes both of them on to the Android™ graphical user interface (GUI) framework. That GUI framework handles the responsibility of appropriately decoding the SSID name and displaying it in the smart phone's WiFi™ scan window or other display. But the Chinese SSID which is encoded in the separate GB code is assumed to be represented UTF-8 compatible code, causing it to be decoded incorrectly by the Android™ Java™ framework, since that framework attempts to decode the GB code assuming the character set information is available in UTF-8 format.
This incompatibility leads to unintelligible or “junk” characters being displayed in the device's scan window. In contrast, since the UTF-8 values for ASCII-based characters are identical, the scan window shows the English SSID correctly on the smart phone.
If an attempt were made to manage the issue for Chinese or other non-English SSIDs outside conventional ASCII set, that approach would cause the supplicant module and Java™ framework module installed on the smart phone to require very complex and possibly unreliable decoding logic to identify whether the SSID name is encoded in ASCII, GB code, or any other encoding scheme that the access point might use. It may be remembered that there is no guideline mandated by the IEEE for access point manufacturers to encode the SSID in any particular coding format. That lack of standardization makes the possible decoding of the access point character set by the smart phone itself that much more difficult at the supplicant/framework level.
It may be desirable to provide systems and methods for enabling stations to connect to wireless hotspots using non-Unicode service set identification information, in which the access point can systematically share which coding scheme is used for the character set used for the SSID broadcast by that device. This information can be passed to the Android™ operating system, Java™ framework, and/or other logic which can then accurately and reliably parse the SSID based on a variety of different character coding schemes, providing visibility into WiFi™ networks by users of a variety of languages.